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Abstract 

The  paper  starts  with  some  background  information  on  the  requirements  regarding  the  use  of  Computer 
Generated  Forces  (CGF).  The  term  itself  will  be  defined  based  on  a  definition  already  given  by  the  US  DoD. 
Basic  or  relevant  technologies  are  described  and  an  overview  on  their  development  given. 


1  Introduction 


1.1  Background/History 

The  end  of  the  Cold  War  has  brought  new  military  tasks  and  types  of  operations  to  NATO.  These  include 
regional  contingency  operations,  Crisis  Management  and  support  of  non-NATO  missions  (UN,  PfP,  WEU, 
etc.).  All  these  have  to  be  executed  in  a  new  environment  with  reduced  forces  and  decreasing  military 
budgets.  The  new  geopolitical  situation  with  expected  reduced  command  levels  and  the  need  to  co-operate 
between  services  as  well  as  between  nations,  call  for  new  concepts  and  systems. 

Modelling  and  Simulation  can  be  used  as  a  tool  to  support  the  development  of  new  concepts  and  systems  for 
the  future.  M&S  also  help  to  better  train  and  use  existing  forces  and  equipment  and  to  improve  operations  in 
a  new  environment. 

Emerging  technologies  will  have  a  great  impact  on  the  implementation  and  on  the  military  use  of  such 
simulation  systems  in  the  future.  Computer  Generated  Forces  as  representations  of  forces  in  simulations 
which  attempts  to  model  human  behaviour  play  a  main  part  in  this  development.  They  offer  support  in  dif¬ 
ferent  application  areas;  examples  are  thinking  automated  opposing  (training  and  exercise),  closed  simulation 
systems  (defence  planning),  Decision  Support  Tools  (operations),  and  virtual  environments  (acquisition  and 
procurement). 


1.2  Present  Situation 

Computer  Generated  Forces  are  still  used  to  some  extent  on  lower  levels  of  command  and  on  weapon  system 
level  (e.g.  Semi-automated  forces).  However  their  behaviour  is  stereotyped  and  only  very  simple  levels  of 
decision-making  is  addressed.  Another  approach  for  specific  low  level  decision  modelling  is  to  use  genetic 
algorithms.  They  are  well  suited  for  some  optimisation  problems,  but  are  not  sufficient  to  be  used  as  a 
general  tool  for  modelling  human  decision-making  in  simulations. 
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In  the  short-term  “Higher  levels  of  command"  are  considered  for  Army  company /battalion  or  Marine  Coips 
platoon/company  level.  For  these  levels  programs  are  launched  to  develop  so-called  Command  Forces 
(CFOR  program  in  US). 

On  the  higher  levels  of  command  at  and  above  brigade  at  the  moment  Computer  Generated  Forces  are  avail¬ 
able,  that  is  not  mature  and  could  be  used  only  for  specific  application  areas  (e.g.  closed  simulation  models 
with  decision  tables  in  Germany). 

CGFs  are  of  considerable  use  in  the  areas  operations  and  acquisition  and  procurement. 

For  military  operations  e.g.  they  could  be  used  within  operational  C3I-systems  to  help  decision  making  by 
modelling  own  decision  processes  and  simulating  the  enemy  as  thinking  opponent. 

In  defence  planning  as  well  as  in  acquisition  and  procurement  Computer  Generated  Forces  could  be  used  as 
tools  in  building-up  simulation  systems  to  lay-out  force  structures  and  individual  weapon  components  taking 
into  account  doctrines  and  tactics. 

In  supporting  Computer  Assisted  Exercises  (CAXs)  CGFs  could  be  used  in  the  Response  and  White  Cells 
and  for  the  representation  of  a  Thinking  Opponent.  This  use  will  help  to  save  money  and  personnel  drasti¬ 
cally. 


2  Definition  of  CGF 

The  definition  of  CGF  for  LTSS/48  is  mainly  based  on  the  definition  given  in  the  US  DoD  Modelling  and 
Simulation  (M&S)  Master  Plan.  This  definition  read  as: 

“A  generic  term  used  to  refer  to  computer  representations  of  entities  in  simulations  which  attempts  to  model 
human  behaviour  sufficiently  so  that  the  forces  will  take  some  actions  automatically  (without  requiring  mcin- 
in-the-loop  interaction ) 


Modelling  and  Simulation  (M&S)  Master  Plan 
US  Department  of  Defence  Oct  1995 

The  term  “forces"  in  the  definition  of  LTSS/48  is  not  restricted  to  military  forces,  because  of  civilian  en¬ 
gagement  in  crisis  and  conflict  scenarios.  This  term  is  defined  as: 

“Military  entities  as  they  are  used  in  conflicts,  peace  support  operations,  and  other  engagements  [operations] 
like  disaster  relief,  and  other  civilian  entities  and  individuals  as  they  are  engaged  in  actions  represented  in  the 
simulation  system." 

The  distinguishing  characteristic  of  CGFs  is  automatic  decision  making.  For  example,  a  manned  simulator 
without  a  crew  is  not  a  CGF.  It  has  no  automated  manner  to  act  on  the  synthetic  battlefield.  Adding  a  hu¬ 
man  crew  also  does  not  make  this  simulator  a  CGF.  In  contrast,  if  a  computer  program  that  commanded  it 
autonomously  supplemented  the  tank  simulator,  this  would  now  be  an  example  of  a  CGF.  In  the  context  of 
constructive  simulations  (e.g.  in  an  exercise  using  a  simulation  model)  a  battalion  whose  behaviour  is  deter¬ 
mined  by  the  computer  may  be  viewed  as  CGF,  though  its  quality  is  a  matter  of  degree.  If  a  human  operator 
controls  the  battalion,  the  battalion  is  not  a  CGF. 

The  degree  of  automated  behaviour  can  span  a  large  range  within  this  view  of  CGFs.  Some  applications  will 
need  relatively  simple  representations  of  decision-making,  while  in  others  the  requirements  are  more  severe. 
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3  Relevant  Technologies 

3.1  Introduction 

This  chapter  is  concerned  with  the  five  technology  aspects  that  are  most  critical  to  the  use  of  CGFs  to  reduce 
costs  while  at  the  same  time  increasing  the  quality  of  the  application  areas  Training  &  Exercises,  Defence 
Planning,  Operations  and  Acquisitions.  The  classification  of  technology  areas  to  support  these  applications 
is  of  course  somewhat  arbitrary,  but  the  LTSS  study  group  as  a  natural  one  quickly  agreed  upon  the  choice 
used  here.  It  served  the  dual  puipose  of  (hopefully)  being  instructive  to  the  reader  and  was  assumed  to  be 
productive  to  study  group  process.  As  far  the  latter  objective  was  concerned,  the  group  process  showed  that 
one  class,  namely  Systems  Science/Architecture,  developed  into  mainly  dealing  with  the  architecture  and 
modelling  of  CGFs.  Consequently,  a  new  group  was  formed  dealing  with  (computer)  Architecture. 

The  technology  areas  are  defined  in  each  of  the  respective  subchapters,  and  are: 

(1)  Synthetic  Environments 

(2)  Architecture 

(3)  Modelling  of  CGF 

(4)  Human  Behaviour  Representation 

(5)  Human/Systems  Interactions 

While  1  deals  with  the  physical  scenarios  of  CGFs,  2  deals  with  how  to  organise  CGFs  so  that  they  commu¬ 
nicate  well  between  them  and  their  environment.  3  and  4  deal  with  respectively  the  modelling  of  CGFs  in 
general,  i.e.  the  interaction  between  the  virtual  human  and  virtual  physical  entities.  4  discuss  the  methods  for 
representing  and  modelling  the  outcomes  of  what  in  the  real  world  are  human  behaviours  and  related  deci¬ 
sion  processes.  5  investigate  technologies  for  interfacing  the  CGF  with  a  human  decision  maker  or  other 
operator. 


3.2  Synthetic  Environment 

3.2.1  Definition 

The  LTSS  working  group  on  CGF  derived  a  definition  (based  on  the  US  DoD  definition)  for  Synthetic  Envi¬ 
ronments  in  the  following  terms,  modification  shown  in  underline: 

Synthetic  Environments  (SE),  “Internetted  simulations  that  represent  activities  at  an 
appropriate  level  of  realism  from  simulations  of  theatres  of  war  to  factories  and  manu¬ 
facturing  processes.  These  environments  may  be  created  within  a  single  computer  or  over  a 
distributed  network  connected  by  local  and  wide  area  networks  and  augmented  by  realistic 
special  effects  and  accurate  behavioural  models.  They  allow  interaction  and  visualization  of 
and  immersion  into  the  environment  being  simulated “. 

The  first  modification  reflects  that  a  Synthetic  Environment  should  only  be  represented  to  an  appropriate 
level  of  detail  required  for  the  particular  application  domain.  The  second  modification  is  the  recognition  that 
the  Synthetic  Environment  allows  the  realistic  interaction  of  CGF  components  rather  than  just  their  visuali¬ 
sation. 

3.2.2  Content  Requirements 

The  content  of  synthetic  environments  can  be  broadly  categorised  into  three  main  components:  the  terrain 
itself  and  its  representation,  meteorological  and  illumination  effects,  and  so  called  “man  made"  effects  such 
as  artificial  objects  and  human  caused  changes  of  terrain  features. 
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3.2.2.1  Terrain 

(1)  Terrain  Representation.  How  should  a  synthetic  terrain  database  be  represented?  Using  TIN 
(triangular  irregular  network)  is  a  convenient  method  of  representing  terrain  because  in  real  life 
terrain  does  not  neatly  form  itself  into  a  regular  triangular  grid  with  a  fixed  diagonal  orientation. 
But  this  is  more  computationally  expensive. 

(2)  Micro  Terrain l.  Could  micro  terrain  representation  be  used  when  dealing  with  terrain  features 
local  to  entities  and  using  a  coarser  representation  at  distance,  considering  the  effect  on  units 
using  high  level  resolution. 

(3)  Database  Generation.  Inevitably,  these  databases  need  to  be  generated  for  the  particular  areas 
of  interest.  Currently,  this  is  very  time  consuming,  as  much  manual  labour  is  required  to  ensure 
consistent  and  realistic  databases.  As  paid  of  the  US  ASTT  (Advanced  Simulation  and 
Technology  Thrust)  programme,  ways  of  automating  this  process  such  that  databases  can  be 
ready  in  8  hours  are  being  researched. 

3.2.2.2  Meteorological,  Illuminants 

(1)  Weather.  The  effect  of  weather  can  play  an  important  role  during  operations.  Not  only  does  it 
have  an  immediate/direct  effect  (visibility,  performance  of  equipment),  but  also  a  time 
dependent  effect  by  changing  the  state  of  the  terrain  (rain  making  ground  bogging,  which 
eventually  dries  out  again).  Thus  considering  at  the  entity  level,  weather  affects  physical 
characteristics  (such  as  trafficability,  speed,  etc),  sensory  systems  (such  as  sights,  laser  and  so 
on)  and  human  behaviour  (such  as  temperature  effects). 

(2)  Illumination.  The  terrain  can  essentially  be  illuminated  by  a  number  of  sources:  the  sun,  the 
moon,  flares  and  lights.  Although  relatively  simple  to  model  solar  illumination,  other  sources 
are  very  important  especially  at  night,  when  night  vision  or  infrared  detection  systems  are 
employed.  Much  harder  to  model  (and  display  on  a  monitor)  is  glint  from  a  reflective  surface 
(e.g.  a  pair  of  binoculars),  which  is  usually  generated  from  a  small  surface,  at  some  distance  and 
is  highly  angular  dependent.  Glint  from  a  vehicle  is  a  major  attribute  to  detection  of  hidden 
vehicles. 

(3)  Sea  state.  This  generally  has  concentrated  on  the  land-sea  interface  (the  surf  zone),  however  the 
effect  of  sea  state  is  important  for  Maritime  operations.  For  example,  the  sea  state  affects  sonar 
performance  (mine  and  submarine  detection),  bottoming  out,  communications,  and  so  on.  The 
depths  of  seas  are  seen  to  be  part  of  the  terrain  description. 

(4)  Air  state.  Similar  to  sea  state,  the  state  of  the  air  has  performance  on  radar,  aircraft  performance 
and  so  on.  This  implies  detailed  modelling  of  cloud,  air  content,  air  currents  etc. 

(5)  Other.  This  covers  other  types  of  effect  such  as  smoke  and  chemical  clouds.  Deployment  of 
smoke  is  a  very  important  operational  tactic  (e.g.  obscurant),  and  as  such  requires  representative 
modelling. 

3.2.2.3  Artificial  Objects  and  Effects 

(1)  Dynamic  Terrain.  In  real  battles  the  terrain  is  altered  either  by  consequence  (shelling, 

detonations)  or  by  design  (protection  such  as  ditches,  trenches,  etc).  These  effects  cause  changes 
to  the  terrain  surface  (craters)  or  to  objects  (destruction  of  bridge),  or  to  both  (road  damage).  In 
the  case  of  the  terrain,  the  representation  needs  the  ability  to  be  modified  to  reflect  the  change. 

In  the  case  of  the  objects,  these  need  to  have  multiple  states  (especially  trees!),  or  for  complex 


1  Normally  the  terrain  surface  is  represented  as  a  regular  grid  of  spot  heights  (e.g.  125  m  intervals).  However,  in  some 
applications  it  is  necessary  to  resolve  the  skin  at  a  higher  resolution  in  some  areas,  for  example  to  represent  a  bunker 
(e.g.  10m),  in  which  to  place  a  tank. 
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objects  multiple  states  of  sub-objects  (e.g.  rooms  in  a  building).  This  is  a  hard  problem,  because 
the  change  must  reflect  on  all  instances  of  the  database.  Are  the  changes  computed  on  a  central 
database  server  then  farmed  out  to  the  various  simulators?  Or.  perhaps  adopt  the  HLA 
philosophy  that  simulators  register  to  a  central  database  server  their  areas  of  interest.  In  any  case 
traffic  is  passed  over  a  network.  It  must  be  ensured  to  reach  its  destination  and  in  a  causally 
correct  fashion. 


3.3  Simulation  System  Architecture 
3.3.1  Introduction 

This  Working  Group  was  created  in  response  to  the  recognition  that  there  is  more  to  military  simulation  sys¬ 
tems  than  the  important  content  of  the  CGFs  themselves.  CGFs  are  only  meaningful  within  a  context  that 
includes  an  entire  simulation  (or  operational)  SYSTEM:  the  CGFs,  the  MMIs,  the  Synthetic  Environment, 
the  human  behavioural  models  (HBMs)  and  other  components  discussed  more  fully  in  Section  2.  Although 
CGFs  may  indeed  be  useful  in  a  number  of  applications  not  requiring  all  of  the  above  components,  many  of 
the  future  uses  of  CGFs  will  involve  applications  requiring  the  integration  with  live  systems  (e.g.C4I),  the 
incorporation  of  multi-modal  man-machine  interface  devices,  the  flexible  combination  of  different  CGFs, 
and  the  embedding  of  the  CGFs  into  very  different  types  of  synthetic  environments.  The  issue  here  is  to  not 
just  develop  an  architecture  that  can  allow  reasonable  interoperability  of  today’s  CGF  components  and  capa¬ 
bilities,  but  rather  to  set  down  the  framework  and  issues  in  order  to  create  an  appropriately  flexible  and  open 
architecture  for  the  future  wide-ranging  applications  of  CGFs.  Paid  of  the  required  flexibility  and  openness  is 
not  only  for  the  economic  and  scientific  benefits  of  quickly  building  CGF  applications  out  of  existing,  di¬ 
verse  components,  but  also  to  give  different  countries  the  flexibility  to  participate  to  the  extent  that  they  want 
to  in  different  applications,  while  still  retaining  the  advantages  of  leveraging  off  of  each  others’  investments 
and  developments  in  this  area.  This  is  an  important  part  of  the  strategy  for  leveraging  off  the  commercial 
marketplace  while  retaining  the  requirements  for  specialised  military  systems;  flexible  architectures  allow 
commercial  partners  to  participate  to  different  degrees. 

Based  on  the  collective  experience  of  the  team,  we  started  with  some  important  assumptions  about  the  type 
of  requirements  we  will  need  for  a  sufficient  simulation  architecture  for  CGFs.  (listed  below)  We  then  spoke 
to  each  working  group  about  the  system  level  architectural  issues  from  their  point  of  view,  and  used  that 
feedback  to  adapt  our  conclusions  and  recommendations. 

This  Working  Group  was  chartered  with  describing  the  important  architectural  issues  in  developing  such  a 
simulation  system,  and  identifying  which  of  the  long-term  goals  of  the  1.  Section  (Application)  Working 
Groups  need  to  be  addressed  as  system  architecture  issues.  We  also  made  some  starting  assumptions  be¬ 
cause  of  our  experiences  in  large-scale  architecture  development: 

Architectures  must  be  specialised  not  only  by  task  and  domain,  but  also  by  specific  classes  of  users. 

Successful  architectures  have  to  be  driven  by  customer  pull  as  a  well  a  policy  push  otherwise  they  will  be¬ 
come  obsolete  due  to  economic  forces. 

Heterogeneous  communities  may  require  different  architectural  services  with  different  constraints  at  each 
layer.  Appropriate  incentives  can  help  individual  and  groups  to  see  co-operating  in  shareable  architectures 
as  an  advantage;  the  shared  infrastructure  and  reusable  components  must  be  harvested,  and  made  easy  to  use 
and  access  globally 

Good  simulation  architecture  should  increase  object  reuse,  decrease  system  risk,  time  to  insert  the  tech¬ 
nology,  and  eventually  model  development  and  maintenance  costs. 

Interoperability  is  matter  of  degree,  depending  upon  the  needs  of  the  simulation,  training,  and  C4I  communi¬ 
ties. 

A  simulation  object  repository  provides  information  on  objects,  their  public  attributes,  associations,  interac¬ 
tions,  level  of  resolution,  and  key  models  and  algorithms  used  to  represent  entities  in  the  simulation. 
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Simulation  architecture  needs  common  transport  layers,  common  messaging  systems,  and  neutral  data  for¬ 
mats  to  provide  limited  interoperability  and  maximum  flexibility.  This  will  allow  commercial  companies 
and  developers  to  gradually  “buy-in”  to  joint  applications. 

Systems  integration  at  the  communication  level  is  a  necessary  but  insufficient  goal.  Semantic  integration  via 
common  ontologies  is  the  critical  challenge. 

Selection  of  open  architecture  and  protocols  needs  to  track  trends  and  standards  in  the  commercial  world  in 
order  to  leverage  off  commercial  investments  for  specific  military  uses. 

3.3.2  Architecture  of  Simulation  Systems 

Architecture  is  critical  for  rapid  construction  and  reuse  of  simulations  and  simulation  components,  because  it 
defines  the  roles  and  responsibilities  of  the  components  in  the  larger  system,  including  not  only  their  inter¬ 
faces  with  each  other  but  also  the  semantics  of  their  expected  interactions.  It  allows  those  roles  to  be  ab¬ 
stracted,  so  that  other  modules  or  components  can  be  used  instead,  provided  they  perform  the  same  roles  and 
carry  out  the  same  responsibilities.  This  feature  allows  interchange  of  different  components  among  different 
systems  when  the  usage  specifications  agree. 

The  question  is  not  whether  to  have  an  architecture.  There  is  always  an  architecture  when  there  is  more  than 
one  function  computed.  The  question  is  whether  to  make  the  architecture  explicit,  so  that  it  can  be  designed 
and  studied  like  any  other  part  of  a  complex  system.  It  is  important  when  we  use  simulations  to  make  in¬ 
formed  decisions  that  we  know  what  the  effects  of  the  architecture  on  the  results  are.  Furthermore,  we  want 
to  increase  the  flexibility  and  as  openness  of  the  CGF  architectures  for  all  the  scientific  and  economic  rea¬ 
sons  cited  above.  Clearly,  there  are  trade-off  studies  that  will  determine  how  much  time  and  money  should 
be  spent  to  improve  the  openness  and  flexibility  of  CGF  architectures,  and  that  is  one  of  the  important  rea¬ 
sons  for  these  topics  to  be  included  in  studies  like  this.  Flowever,  it  is  also  the  opinion  of  this  expert  working 
group  that  the  requirements  for  relatively  open  architectures  are  almost  always  underestimated  in  the  military 
applications  where  there  are  serious  needs  to  quickly  improve  the  performance  of  existing  systems  with  the 
newest  capabilities.  It  is  also  our  opinion  that  even  preliminary  results  have  shown  the  benefits  for  military 
systems  of  reasonably  open  architectures. 

Because  architecture  is  an  integration  concept,  a  way  to  provide  a  common  semantic  framework  for  a  collec¬ 
tion  of  models,  or  to  put  back  together  components  that  have  been  developed  separately,  our  Working  Group 
discussed  important  issues  with  the  other  Technical  Working  Groups,  to  identify  those  that  are  primarily 
architectural  issues  or  that  would  affect  or  be  affected  by  any  proposed  architecture. 

Our  puipose  in  this  Working  Group  was  not  to  propose  a  particular  architecture,  or  even  an  architectural 
style,  but  to  identify  properties  that  any  architecture  should  have,  and  to  collect  context  conditions  that  any 
architecture  should  accommodate.  No  single  architectural  style  suffices  for  all  the  different  applications  of 
CGFs  or  all  the  different  uses  of  simulation.  Each  simulation  developer  will  of  course  have  a  unique  mix  of 
requirements  and  application  interests,  so  the  architecture  that  will  be  used  will  depend  on  that  mix.  Our 
puipose  in  this  Working  Group  was  to  show  how  new  developments  in  system  architectures  can  help  make 
these  separate  systems  interoperate  more  easily. 

A  simulation  system  will  have  many  different  kinds  of  components:  CGFs,  Synthetic  Environments,  Models 
of  domain  entities,  forces,  tasks,  Analysis  Tools,  Scenario  Generation  Tools,  Visualisation  Tools,  Mobile 
Devices,  Multimodal  Human-Machine  Interfaces,  C4I  systems,  Embedded  evaluation  and  monitoring  agents, 
algorithms  for  continuous,  discrete  event  and  Monte  Carlo  simulations,  embedded  tutor  components,  tools 
for  after  action  review,  and  many  other  kinds  of  automated  assistance.  In  addition  to  these  resources  that 
have  immediate  utility  to  the  user,  there  are  a  number  of  resources  that  are  necessary  components  to  man¬ 
aging  these  resources  in  a  flexible  way;  they  are  indirectly  seen  by  users  in  the  ease  with  which  the  system 
can  be  tailored  because  of  the  needs  of  different  users,  new  field  requirements  or  new  parts  of  the  system. 
Among  these  types  of  components  are  domain- specific  models  that  define  the  configuration  for  a  subset  of 
components,  with  the  detailed  specialisations  that  will  allow  them  to  be  tailored  for  a  given  application. 
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Even  though  we  can  take  advantage  of  good  object-oriented  approaches  and  the  use  of  meta-data  approaches, 
a  single  object  or  component  cannot  contain  inside  itself  all  of  the  information  required  at  the  whole  system 
level.  That  is,  local  consistency  of  the  information  within  an  object,  or  even  each  one  of  a  collection  of  ob¬ 
jects,  does  not  guarantee  global  consistency.  There  are  many  attributes  of  a  system  that  must  be  analysed 
(generally  using  different  methods)  at  both  the  whole  system  and  the  local  levels  (e.g.,  risk,  performance, 
validity). 

It  is  our  view  that  the  system  should  perform  as  much  component  integration  and  management  as  possible, 
instead  of  the  organisation  or  simulation  owners,  because  automatic  assistance  makes  it  much  more  likely 
that  the  simulation  components  are  consistent  with  each  other  and  with  the  assumptions  of  the  simulation 
study,  much  more  likely  that  the  component  interfaces  arc  properly  used,  and  much  more  likely  that  auto¬ 
matic  reconfiguration  and  instrumentation  tools  can  be  used  successfully. 

Even  if  we  were  all  to  agree  that  this  list  is  complete,  i.e.,  it  contains  all  of  the  important  components  of  a 
simulation  system,  we  still  need  flexibility  in  the  architecture,  because  components  and  even  architectures 
change  with  technology.  That  is,  the  variety  of  components,  the  different  kinds  of  uses  of  components,  and 
the  dynamic  nature  of  technology,  together  requires  a  flexible  interconnection  architecture.  It  is  therefore 
necessary  to  define  the  semantics  of  the  shareable  data,  that  is,  the  meanings  that  the  users  of  that  data  are 
expected  to  attach  to  it,  rather  than  fixing  the  structure  if  the  systems  that  will  use  the  data.  It  is  convenient 
to  define  the  syntax  of  the  data  (data  formats  and  structures),  but  not  nearly  as  important  as  defining  the  se¬ 
mantics.  If  the  data  syntax  is  explicit  for  each  data  item,  then  it  can  be  translated  or  converted  appropriately 
as  needed. 


3.4  Modelling  of  CGFs 

3.4.1  Introduction 

The  scope  of  this  section  is  to  identify  the  technologies  required  to  achieve  good  rational  /  cognitive  models 
within  a  CGF. 

One  basic  assumption  is  that  the  physical  behaviour  of  the  computer-generated  force  is  fairly  well  under¬ 
stood  whereas  the  rational  and  human  factors  aspects  are  not.  Another  assumption  is  that  a  good  ra¬ 
tional  /  cognitive  model  of  a  CGF  can  be  incorporated  into  any  simulation  that  represents  its  physical  part  or 
into  its  real-world  physical  component. 

As  the  architecture  of  the  simulation  system  plays  an  important  role  in  the  effective  use  of  CGFs,  it  will  be 
discussed  briefly  in  this  section.  Next,  a  generic  structure  of  the  rational  /  cognitive  part  of  the  CGF  will  be 
described.  The  technologies  that  are  relevant  for  the  development  of  each  of  the  modules  in  this  structure  are 
derived.  The  criticality  and  maturity  of  these  technologies  and  the  likelihood  of  being  developed  for  com¬ 
mercial  puiposes  are  assessed.  Combined  with  an  overall  analysis  of  the  contribution  of  CGFs  to  the  various 
application  areas  long-term  objectives,  a  ranking  of  the  technological  areas  that  require  military  funding  is 
derived. 

3.4.2  Architecture 

The  architecture  of  a  simulation  system  as  shown  in  Figure  1  enables  a  flexible  organisation  of  the  elements 
of  the  simulation,  based  on  the  requirements  of  the  area  where  it  will  be  applied. 

The  existence  of  a  common  “language”  allows  heterogeneous  elements  to  interact.  Furthermore,  the  same 
element  can  be  implemented  in  different  ways  without  impacting  on  the  rest  of  the  simulation.  In  Figure  1, 
this  common  language  is  referred  to  as  “Interoperability  Protocol”. 

The  interoperability  protocol  consists  of  three  layers: 

(1)  The  communication  layer,  which  provides  the  mechanism  for  the  physical  transport  of  messages 
between  the  components  of  the  simulation  system. 
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(2)  The  “grammar”  layer,  which  provides  the  words  and  rules  for  building  the  messages. 

(3)  The  “semantics”  layer,  which  contains  the  “dictionary”  to  attribute  meaning  to  and  extract 
meaning  from  the  messages. 

C3I  systems,  either  in  an  operational  or  a  training  mode,  are  integrated  into  the  simulation  system.  For  train¬ 
ing  or  analysis,  a  duplication  of  an  existing  C3I  system  or  a  prototype  of  a  new  C3I  system  can  be  inserted 
into  the  simulation  in  order  to  avoid  disruption  to  the  real-world  operational  C3I  system. 

In  analogy  to  the  C3I  system,  interaction  with  the  environment  can  take  place  with  a  synthetic  or  a  real-world 
representation.  The  specific  characteristics  of  the  synthetic  environment  are  addressed  in  section  4.2. 

The  particular  part  of  the  architecture  dealing  with  the  rational  /  cognitive  model  of  CGFs  and  their  inter¬ 
action  will  be  described  in  the  following  paragraphs.  The  part  of  the  architecture  dealing  with  CGFs  and  their 
interaction  to  humans  involves  different  techniques  and  will  be  addressed  in  section  4.6. 


Operational 
C3I  System 


Training  or 
Prototype 
C3I  System 


Interoperability  Protocol 


Semantics 


Vocabulary  and  Grammar 


Communications 


/  /  / 

Human 

controlled 

Virtual 

Systems 

Terrain  Meteo  Man-made 

/Light  geo  features 

Synthetic  Environment 

Figure  1 :  A  potential  Simulation  System  Architecture 

3.4.3  CGF  modules 

As  shown  in  Figure  1,  the  organisation  of  the  CGFs  should  reflect  the  structure  of  the  organisation  they 
represent.  In  case  of  a  military  organisation,  this  generally  implies  a  strictly  hierarchical  structure.  Within  a 
military  staff,  however,  this  strict  hierarchy  does  not  necessarily  apply  and  a  collaborative  group  decision¬ 
making  structure  needs  to  be  reflected.  Hence  a  CGF  representing  a  specific  level  of  command  would  be 
broken  down  into  a  number  of  CGFs  representing  its  respective  staff  elements.  To  communicate  to  each 
other,  the  CGFs  would  use  the  interoperability  protocol  discussed  in  the  previous  section. 

Considering  the  ability  to  represent  all  elements  of  the  civil  /  military  organisation,  it  is  suggested  that  a  suf¬ 
ficiently  detailed  model  to  meet  the  various  application  areas’  requirements  could  be  a  solution  to  simulating 
at  various  levels  of  information  aggregation.  Indeed  information  would  be  processed  through  CGFs  down  to 
the  level  of  detail  of  the  synthetic  environment  and  would  be  reported  upwards  through  CGFs  to  the  required 
level  of  information  presentation. 
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In  order  to  derive  basic  technologies  to  develop  good  CGFs,  the  internal  structure  of  a  CGF  was  developed, 
as  illustrated  in  Figure  2.  This  proposed  structure  is  derived  from  a  model  of  the  decision  making  process. 
Alternative  structures  could  be  defined  based  on  a  different  model.  Each  of  the  modules  corresponding  to  a 
step  in  the  decision  making  process  can  be  characterised  by  a  set  of  functions.  It  can  be  expected  that  alter¬ 
native  structures  would  also  include  these  basic  functions. 


Figure  2:  Modules  of  the  CGF  rational  /  cognitive  model 


The  role  of  each  of  the  modules  can  be  described  as  follows: 

(1)  the  data  collection  module  is  responsible  for  gathering  the  detailed  data  elements  as  instructed 
by  the  situation  assessment  module; 

(2)  the  situation  assessment  module  defines  the  detailed  data  requirements  that  need  to  be  collected, 
interprets  the  mission  received  by  the  CGF,  updates  the  current  assessment  of  the  situation  and 
defines  and  monitors  critical  and  meaningful  events; 

(3)  the  option  generation  module  develops  courses  of  action  based  on  the  triggering  event,  mission 
statement  and  current  situation  assessment; 

(4)  the  decision-making  module  evaluates  the  various  courses  of  action  and  ranks  them  according  to 
a  set  of  pre-determined  and  derived  criteria.  It  will  also  support  the  negotiation  process  between 
CGFs  or  human  decision  makers  that  may  be  required  to  develop  a  solution  for  the  larger 
context  in  which  the  CGFs  decision  is  included; 

(5)  the  communication  module  supports  the  exchange  of  data  between  the  CGF  and  all  other 
elements  of  the  simulation  system.  It  transforms  data  into  the  appropriate  format  for  local  and 
external  interpretation. 

The  sequence  of  decision-making  steps  can  be  either  course  of  action  or  goal  driven.  Some  of  the  modules 
e.g.  situation  assessment,  may  operate  in  parallel  with  others  while  others  e.g.  option  generation  need  to  be 
triggered  specifically.  Human  factors  like  stress,  fear,  fatigue  etc.  have  their  influence  on  all  of  the  decision¬ 
making  steps.  They  are,  however,  considered  to  fall  outside  the  scope  of  this  section. 
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Each  of  the  modules  are  defined  as  consisting  of  the  following  functions: 


Module 

Function 

Description 

Data  Collection 

Get  data  request 

Receive  detailed  data  specification 

Find  the  data 

Query  sources 

Define  sources 

Prepare  the  data 

Format  retrieved  data 

Provide  data  reference 

Report  on  data  source 

Situation  Assessment 

Produce  data  requests 

Specify  detailed  data  requirement 

Interpret  and  fuse  data 

Merge  and  attribute  meaning  to  data 

Monitor  critical  events 

Define  critical  and  meaningful  event  criteria. 
Monitor  events  and  assess  impact. 

Maintain  updated  situation 

Adapt  perception  of  current  situation  and  verify 
consistency. 

Option  Generation 

Generate  possible  courses 
of  action 

Taking  into  account  mission,  environment,  own 
and  other  forces,  develop  feasible  courses  of  action 
(including  empty  set) 

Decision  Making 

Rank  options 

Derive  variable  criteria. 

Combine  pre-determined  and  derived  criteria. 
Analyse  courses  of  action. 

Goals  decision  making 
approach 

Derive  intermediate  goals. 

Negotiate 

Re-define  constraints  and  range  of  acceptable 
solutions.  Monitor  and  enforce  convergence. 

Communication 

Interface 

With  external  elements  and  CGF 

Report 

To  other  CGFs  and  external  elements 

Table  2:  Functions  of  the  modules  of  the  CGF  rational  /  cognitive  model 
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Module 

Function 

Technology 

Criticality 

Data  Collection 

Get  data  request 

Current  database  and  browsing 
technologies 

H 

Find  the  data 

Data  mining  (e.g.  Selection  and 
discrimination  techniques) 

H 

Knowledge  discovery 

L 

Pattern  recognition 

L 

Knowledge  based  systems 

L 

Prepare  the  data 

Current  database  and  browsing 
technologies 

H 

Provide  data  reference 

Current  database  and  browsing 
technologies 

H 

Situation  Assessment 

Produce  data  requests 

Knowledge  discovery 

H 

Translation  techniques 

H 

Rule-based  systems 

H 

Interpret  and  fuse  data 

Task  and  domain  specific  data  fusion 
algorithms 

H 

Pattern  recognition 

H 

Neural  networks 

M 

Image  recognition 

M 

Natural  language  processing 

H 

Monitor  critical  events 

Flexible  object  schema  for  situation 
description 

H 

Maintain  updated  situation 

Blackboards  for  consistency 
maintenance 

H 

Knowledge  based  systems 

H 

Option  Generation 

Generate  possible  courses 
of  action 

Search  algorithms 

H 

Simulation 

M 

Knowledge  based  systems 

H 

OR 

L 

Fuzzy  logic 

M 

Decision  Making 

Rank  options 

Simulation 

H 

OR 

H 

Fuzzy  Logic 

H 

Goals  decision  making 
approach 

Planning  techniques 

H 

Search  techniques 

H 

Negotiate 

Cooperative  planning 

HH 

Communication 

Interface 

Speech  recognition 

H 

Image  recognition 

H 

Gesture  recognition 

L 

Report 

Speech  generation 

M 

Image  generation 

M 

Table  3:  Technology  areas  relevant  to  the  CGF  functions 


3.4.4  Basic  technologies 

Having  defined  the  various  constituent  functions,  the  technologies  required  to  develop  them  can  be  listed. 
They  are  shown  in  Table  3.  along  with  an  appreciation  of  the  criticality  of  the  technologies  to  the  specific 
function  of  the  CGF  module.  Criticality  is  measured  as  being  H(igh),  M(medium)  or  L(ow). 
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3.5  Human  Behaviour  Representation 

This  section  is  concerned  with  one  single  aspect  of  a  CGF  -  how  human  decision-making  behaviour  is  repre¬ 
sented  within  a  typical  CGF.  Common  understanding,  also  reflected  in  the  technology  working  group  re¬ 
sponsible  for  examining  this  technology  area,  is  that  Fluman  Behaviour  Representation  (FIBR)  is  the  most 
difficult  issue  in  devising  successful  future  CGFs  with  high  quality.  Technically,  one  can  think  of  a  FIBR  as 
a  software  module  that  "interacts"  with  the  rest  of  a  CGF  and/or  with  the  real  world  -  depending  on  the  ap¬ 
plication.  This  interaction  must  be  controlled  through  the  simulation  architecture,  via  FIBR  objects  that 
access  information  from  real  or  simulated  sensors  through  real  or  simulated  C4I  systems.  The  nature  of  this 
interaction  is  described  in  the  CGF  Modelling  and  in  the  Architecture  chapters  and  will  only  briefly  be  re¬ 
ferred  to  here. 

There  are  two  main  approaches  to  FIBR.  One  is  mainly  concerned  with  mimicking  human  thought  processes 
and  is  hence  here  called  FIBP  (Fluman  Behaviour  Process).  The  other  is  more  concerned  with  a  correct  repre¬ 
sentation  of  the  output  of  a  thought  process,  and  is  here  termed  FIBO  (Fluman  Behaviour  Output).  The  im¬ 
plementation  of  FIBR  in  software  is  here  referred  to  as  FIBM  (Fluman  Behaviour  Model). 


3.6  Human/System  Interactions  (H/S-I) 

In  the  following  are  short,  mid,  and  long-term  technology  solutions  for  FI/S-I  systems  in  CGF  described. 
Short  term  is  defined  as  currently  off  the  shelf  or  within  three  years  of  being  off  the  shelf.  Mid  term  is  de¬ 
fined  as  from  4  to  10  years  out  and  long  term  is  from  10  to  15  years  out. 

3.6.1  Results  and  Timelines  for  Training  and  Exercise  Problem  Areas 

Table  4  briefly  lays  out  the  results  for  training  and  exercise. 


Training  & 
Exercise 

Short 

Medium 

Long 

Natural  interface 

•  Speech  recognition 

•  video  conferencing 

•  realistic  graphics 

•  gestures  for  gross 
manipulation 

•  Facial  expression 
recognition 

•  natural  language 
processing 

•  reliable  gesturing 

•  systems 

•  Realistic  voice 
synthesis 

•  VR 

•  transparent  & 
natural  interface 

Time  compression 

•  Expansion  to  allow 
students  to  catch  up 

•  compression  to  save 
time,  may  be  used  to 
create  stress 

•  Study  effects  of  time 
compression  on 
learning  and 
operational 
performance 

•  alternative  training  and 
pre-exercise  strategies 

•  Can  the 

manipulation  of 
time  simulate 
wartime  stress 

Multi-modal 

•  Output:  audio,  still  & 
motion  video, 
graphics. 

•  Input:  keyboard, 
mouse/  trackball, 
touch  panels,  single 
utterance  speech. 

•  Video  conferencing 
has  elements  of  all 

•  R&D  into  adding 
modes  (touch,  pressure, 
tactile). 

•  Improve  current  modes 
(360  sound),  3-D. 

•  What  is  the  effect  of 
cultural  influences  and 
individual  differences 
on  interface 
effectiveness 

•  Smell,  taste. 

•  Using  human 
sensory  system  to 
create  stress. 

•  Total  immersion 
systems. 

Table  4:  The  working  groups  results  for  training  and  exercise 
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Most  of  these  technologies  are  being  developed  independently  of  any  military  or  NATO  intervention  since 
they  would  add  value  to  commercial  computer  products  as  well.  However,  there  are  two  research  areas, 
which  should  be  pursued  as  a  result  of  this  conference: 

(1)  The  effects  of  time  compression  and  expansion  on  learning  and  performance 

(2)  The  effect  of  cultural  differences  on  interface  design  and  effectiveness. 

3.6.2  Results  and  Timelines  for  Defence  Planning  and  Operational  Analysis  Problem  Areas 

Table  5  provides  the  timeline  for  the  issues  raised  by  Defence  Planning  and  Operational  Analysis. 


Force 

Planning 

Short 

Medium 

Long 

Abstract 

concepts 

•  Text 

•  maps 

•  flags 

•  simple  icons 

•  Media  resources 
analysis 

•  cultural  metrics 

•  probability  of 
particular  events 

•  Set  realistic  and 
limited  goals 

•  Program  should  be  a 
series  of  well 

defined,  short  term 
projects 

Drill  down 

•  Lot  of  data 

•  problem  is 
converting  to 
information 

•  Primarily  self 
selection 

•  Optimum  data  base 
organisation  for 
human  use 

•  What  information  is 
needed  by  whom  and 
when  do  they  need  it? 

•  Intelligent  agents 
subject  to 
verification 

Table  5:  Timeline 


The  primary  research  goals  here  are  to  establish  ways  to  organise  data  to  that  can  be  used  by  the  right  people 
at  the  right  time.  A  separate,  but  equally  difficult  problem,  is  to  capture  abstract  concepts  (i.e.,  religious  be¬ 
liefs,  tribal  loyalty)  in  some  concrete  form  that  can  then  be  represented  in  a  useable  form  for  decision  makers 
and  planners. 

The  need  for  intelligent  agents,  which  are  subject  to  verification,  should  also  provide  a  high  priority  research 
thrust.  Commanders  want  information  they  can  trust.  An  intelligent  agent  must  provide  that  information  and 
also  be  able  to  respond  to  queries  about  it.  The  information  provided  should  not  be  more  precise  than  the 
truth  based  on  “fog  of  war”.  Therefore  there  are  two  research  areas  recommended  by  the  H/S-I  working 
group  to  meet  the  Force  Planning  needs: 

(1)  How  to  represent  abstract  concepts  in  operationally  meaningful  terms. 

(2)  The  development  of  intelligent  agents,  which  can  be  subjected  to  verification. 
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3.6.3  Results  and  Timelines  for  Operations  Technologies  Problem  Areas 

Table6  provides  the  timeline  for  H/S-I  responses  to  the  Operations  area. 


Operations 

Short 

Medium 

Long 

Agents 

•  Organisers 

•  formats 

•  push  technology 

•  Inference  agents 
(what  information 
do  staff  need?) 

•  Use  simulation  to 

determine  what  is 
the  necessary  and 
sufficient 

information  for 

decision  making 

•  Intelligent  agents 
subject  to 
verification 

Expressing  the 
complex 

•  Improved 
navigational 
techniques 

•  advanced  graphing 

•  visualisation 

•  display  of 
multidimensional 

data 

•  Develop  a  theory 
for  display  of 
multidimensional, 
complex 
information 

•  Automated 
processing  and 
displaying  of 
complex  data. 

•  Task  and  individual 
based  display 

Random  insertion 
of  unplanned 
events 

•  Stochastic  models 

•  unexpected  failures 

•  Critical  event 

detection 

•  automated  checklist 

for  critical  event 

detection 

•  automated 

dissemination  of 

warnings 

•  Automated 

detection  of  critical 

events 

•  display  of  critical 

events 

Table6:  Timeline 
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Notes  for  Slide  2 


The  Logical  or  Functional  Perspective.  This  view  focuses  on  the  logical  or  functional 
interrelationship  of  the  CAX  System  Components  and  constitutes  the  Functional 
Architecture  of  the  CAX  System.  The  Functional  CAX  Architecture  described  in  1  is 
derived  from  military  operational  needs  and  it  is  not  constrained  by  any  system  topology 
or  other  CAX  System  Implementation  considerations. 

The  CAX  System  Topology.  This  view  defines  and  evaluates  available  options  for 
providing  the  CAX  functionality.  As  the  first  step  in  this  process,  six  options  are  identified, 
each  with  a  different  degree  of  integration  of  CAX  with  CCIS  and  with  a  different  degree 
of  distribution  of  the  CAX  functionality  itself.  The  second  step  is  then  to  compare  the  CAX 
Architectural  Options  and  come  up  with  advantages  and  disadvantages  of  each  of  them. 
This  analysis,  provided  in  Section  2,  is  based  on  the  Functional  Architecture  as  well  as  on 
a  set  of  assessment  criteria  such  as  User  Satisfaction,  Implementation/Operation  & 
Maintenance  Cost,  Security,  Technological  Trends  and  Flexibility. 
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Notes  for  Slide  2  (Continued) 


The  CAX  System  Physical  Architecture  describes  hardware  and  software 
components  and  their  interrelationships  for  the  CAX  system.  In  future  CCIS,  as  in 
other  modern  information  systems,  this  physical  architecture  will  not  play  the  role  it  is 
playing  today.  New  technologies  available  to  implement  functions  on  distributed 
systems  and  global  data  links  will  make  it  possible  to  concentrate  on  the  functional 
and  topological  design  of  the  systems.  Even  changes  from  one  physical  architecture 
to  another  regarding  the  distribution  of  functions  in  a  network  will  be  no  major 
problem  and  will  give  the  opportunity  to  decide  on  topological  architectures  as 
described  in  chapter  2  in  accordance  with  the  exercise  requirements.  Chapter  3 
introduces  the  discussion  on  possible  implementation  options  for  the  different 
topological  CAX  architectures. 
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Definition  of  CGF 

“A  generic  term  used  to  refer  to  computer 
representations  of  entities  in  simulations  which 
attempts  to  model  human  behaviour  sufficiently 
so  that  the  forces  will  take  some  actions 
automatically  (without  requiring  man-in-the-loop 
interaction) 

Modelling  and  Simulation  (M&S)  Master  Plan 
US  Department  of  Defence  Oct  1995 
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Definition  of  CGF  from  LTSS/48  on  CGF 

The  term  “ forces “  in  the  definition  of  LTSS/48  is 
not  restricted  to  military  forces,  because  of 
civilian  engagement  in  crisis  and  conflict 
scenarios.  This  term  is  defined  as: 

“Military  entities  as  they  are  used  in  conflicts, 
peace  support  operations,  and  other 
engagements  [operations]  like  disaster  relief,  and 
other  civilian  entities  and  individuals  as  they  are 
engaged  in  actions  represented  in  the  simulation 
system." 
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Background 

•  Assumption  That  a  Good  Rational/Cognitive 
Model  of  a  CGF  Can  Be  Incorporated  Into  Any 
Simulation  That  Represents  Its  Physical  Part  or 
Into  Its  Real-world  Physical  Component 

•  The  Physical  Behaviour  of  the  Computer- 
Generated  Force  Is  Fairly  Well  Understood 
Whereas  the  Rational  and  Human  Factors 
Aspects  Are  Not 

•  CGF  Still  Used  on  Lower  Level  of  Commands 
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•  CGF  Offer  Support  in  Different  Application  Areas: 
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■  Defence  Planning 

•  Support  to  Operations 

■  Acquisition  and  Procurement 
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Extensive  Re-use  Within  Phases  and  Across  Acquisition  Programs 


Dr.  Uwe  K.J.  Dompke 


SAS-LS222  Lecture  Series 
’’Simulation  of  &  for  Military  Decision  Making” 


7-16 


CGF  -  Background,  Definition  and  Basic  Technologies 


ORGANIZATION 

Basic  Technologies 

•  Synthetic  Environments 

•  Simulation  System  Architecture 

•  Modelling  of  CGF 

•  Human  Behaviour  Representation 

•  Human/Systems  Interactions 
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Synthetic  Environment  Definition 

“Internetted  simulations  that  represent  activities  at  an 
appropriate  level  of  realism  from  simulations  of  theatres  of 
war  to  factories  and  manufacturing  processes.  These 
environments  may  be  created  within  a  single  computer  or 
over  a  distributed  network  connected  by  local  and  wide 
area  networks  and  augmented  by  realistic  special  effects 
and  accurate  behavioural  models.  They  allow  interaction 
and  visualization  of  and  immersion  into  the  environment 
being  simulated 
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SE  Content  Requirements 

•  The  Terrain  Itself  and  Its  Representation 

•  Meteorological  and  Illumination  Effects 

•  So  Called  “Man  Made"  Effects  Such  As  Artificial 
Objects  and  Human  Caused  Changes  of  Terrain 
Features 
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Terrain 

•  Terrain  Representation 

•  Micro  Terrain 

•  Database  Generation 
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Meteorological,  Illuminants 

•  Weather 

•  Illumination 

•  Sea  state 

•  Air  state 
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Artificial  Objects  and  Effects 

•  Dynamic  Terrain  -  Terrain  Is  Altered  Either  by 
Consequence  (Shelling,  Detonations)  or  by 
Design  (Protection  Such  As  Ditches,  Trenches, 
Etc) 

■  Changes  to  the  Terrain  Surface  (Craters)  or 

■  To  Objects  (Destruction  of  Bridge),  or 
-  To  Both  (Road  Damage) 
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Simulation  System  Architecture 

•  Need  for  an  Appropriately  Flexible  and  Open 
Architecture  for  the  Future  Wide-ranging 
Applications  of  CGFs. 

•  Economic  and  Scientific  Benefits  of  Quickly 
Building  CGF  Applications  Out  of  Existing, 
Diverse  Components  Even  Multinational 
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Interoperability  Protocol  Layers 

•  The  communication  layer,  which  provides  the 
mechanism  for  the  physical  transport  of 
messages  between  the  components  of  the 
simulation  system. 

•  The  “grammar”  layer,  which  provides  the  words 
and  rules  for  building  the  messages. 

•  The  “semantics”  layer,  which  contains  the 
“dictionary”  to  attribute  meaning  to  and  extract 
meaning  from  the  messages. 
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CGFs  Modules 
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